HI！大家好，我是 Shammi 😊

當我開始思考如何在 Colab 環境下部署一個 Telegram 機器人來接收訊息時，內心其實是充滿期待的！然而，在試著執行的過程中遇到無法遇期的原因。經過測試後，我發現 Webhook 模式在 Colab 這種特殊的雲端筆記本環境下，潛藏的技術挑戰無法穩定輸出。

所以，在今天，我將分享為什麼 Telegram 平台最後採用「長輪詢 (Polling)」模式，以及這個選擇如何讓我成功讓機器人動了起來！

🌐 一、為什麼我選擇了『長輪詢』模式？

雖然 Telegram Bot API 提供了兩種訊息接收方式：Polling (輪詢) 🔄 和 Webhook (掛鉤) 🎣，但經過仔細評估，我認為『長輪詢』在 Colab 環境下是更務實的選擇，讓我能更順利地啟動機器人。

👉 Polling (輪詢) 🔄： 這是我的機器人程式會「主動」向 Telegram 伺服器詢問新訊息的方式。

• 優點： 設定超級簡單，不用搞什麼公開 URL、伺服器，直接跑程式就好。對我這種急著想看到成果的參賽者來說，超級方便！
• 缺點： 效率會比較低，因為即使沒有訊息它也會一直問，而且訊息回覆會有些許延遲。

🌐 二、深入解析：Webhook 模式的挑戰

儘管 Webhook 在理論上聽起來很棒，能讓機器人即時回應、資源效率高，但在 Colab 這種雲端筆記本環境中實作起來，真的有許多難以避免的挑戰，讓我最終決定轉向長輪詢模式。

1️⃣ 公開 URL 的難題：依賴 ngrok 🔗

👉 Webhook 模式要求機器人提供一個公開且持續可訪問的 URL。然而，Colab 筆記本並沒有固定且公開的 IP 位址。

👉 這意味著我們必須依賴 ngrok 這樣的第三方工具，來建立一個臨時的隧道，將 Colab 內部運行的服務映射到一個外部可訪問的網址。ngrok 的穩定性、連接時序，以及其本身可能帶來的連接問題，都可能成為服務中斷的原因。

2️⃣ 伺服器與事件循環的複雜性：Flask 與 asyncio 💥

👉 Webhook 需要一個**網頁伺服器（例如 Flask）**來接收來自 Telegram 的 HTTP POST 請求。在單一的 Colab Python 環境中，同時運行 Flask 伺服器的阻塞式事件循環和 python-telegram-bot 內部可能存在的異步事件循環，極易發生衝突。

👉 這可能導致 RuntimeError: This event loop is already running（事件循環衝突）或其他難以追蹤的 AttributeError 或 NameError，使得程式碼無法正常執行或穩定運行。管理這些底層的異步和多執行緒邏輯，對初學者來說是巨大的挑戰。

3️⃣ 除錯與維護的困境 🕵️‍♀️

👉 Webhook 模式的錯誤可能發生在網路層（ngrok 連接）、伺服器層（Flask 設定）、Python 異步執行層，或是應用程式邏輯層。多個環節都可能出錯，使得問題定位和除錯變得非常困難和耗時。

這些挑戰都增加了在 Colab 中部署 Webhook 機器人的複雜度和不確定性，讓其難以達到穩定的運行狀態。因此，我決定採用更直接、更易於管理的長輪詢模式，來確保機器人能夠順利為大家服務！

🌐 三、必要工具：BotFather 與 ngrok (針對 Webhook 模式)

儘管我選擇了長輪詢，但如果你未來想挑戰 Webhook 模式，或只是想了解其運作原理，以下兩個工具會是關鍵：

👉 BotFather 🤖： 這是 Telegram 官方提供的一個特殊機器人。你需要透過它來創建你的 Telegram 機器人，並取得 Bot Token。此外，如果你要設定 Webhook，也需要使用它來設定你的 Webhook URL。

👉 ngrok 🔗： 由於 Colab 環境沒有公開的 IP 位址，你需要使用 ngrok 來建立一個安全的隧道，將你 Colab 中運行的服務映射到一個公開可訪問的 URL。在 Webhook 模式下，Telegram 將會把訊息發送到這個 ngrok 提供的 URL。

總結

經過不斷測試下，我確立在 Colab 環境下部署 Telegram 機器人的最佳策略——那就是「長輪詢 (Polling)」模式！這次的經驗讓我也學會該如何選擇正確的部署策略，比起盲目追求「理論最佳」更重要。在 Colab 的限制下，長輪詢模式讓我擺脫了技術困境，成功讓機器人動起來！所有實現這個模式的完整且可運行的程式碼細節和操作步驟，都將明天的篇章呈現囉！明天見！